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Remarks 

Applicant respectfully requests reconsideration of the above-identified application in 
view of the following remarks, amendments to the claims and added claims. 

35 U.S.C. 112 Rejection of Claim 19 

Claim 19 has been amended to correct a typographical error - claim 19 depends from 
claim 14 and not claim 1 . It is submitted that claim 19 satisfies 35 U.S.C. §1 12 in all respects. 

Prior Art Rejections 

Claims 1-3, 5-6, 8-11, 12-13 and 18-26 were rejected under 35 U.S.C. §102 as being 
anticipated by U.S. Patent Publication No. 2005/0010653 ("McCanne et al."). Claims 4 and 14- 
16 were rejected under 35 U.S.C. §103 as being unpatentable over McCanne in view of U.S. 
Patent No. 6,160,843 ("McHale et al."). Claims 7 and 17 were rejected under 35 U.S.C. §103 as 
being unpatentable over McCanne in view of U.S. Patent Publication No. 2002/0143951 ("Khan 
et al."). 

35 USCS 102 Rejection of Claims L 2. 5 .6. 8. 9. 11-13. 18-20 and 24-26 

Claims 1 and 21 were discussed together in the rejection thereof on page 3 of the Office 
Action. We have assumed that the Examiner meant to reject independent claim 12 with claim 1, 
rather than dependent claim 21, because claim 21 is separately discussed later in the Office 
Action and claim 12 is not. 

Claim 1 

Amended claim 1 claims a method for providing streamed electronic content to a 
plurality of user terminals in a client network from at least one remote electronic content source. 

According to the method claimed in claim 1, requests are received from two or more user 
terminals in the client network for streamed content from the at least one remote electronic 
content store, and a streamed unicast transmission is provided of the requested content for receipt 
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by a client-side computer in the client network, e.g., "any suitable computer, network, or other 
electronic processing unit capable of requesting, receiving, and/or manipulating content streams 
as further described herein." (See paragraph [0018].) 

On the client side of the network, the method of claim 1 provides for the streamed unicast 
transmission to be received in and processed by the client-side computer, and for the client-side 
computer to distribute the processed streamed content to each of the requesting plurality of user 
terminals in the client network. 

As mentioned, claim 1 was rejected in the Office Action as being anticipated by 
McCanne et al. This rejection, as it was applied to claim 1 and as it may be applied to amended 
claim 1 , is traversed for the following reasons. 

McCanne et al. is concerned with building out a content distribution network to the 
network edge, and not in the client network as claimed in claim 1 . The peering arrangements 
discussed in McCanne et al. are between ISPs, and are not in the client network. This is clear 
from paragraphs [0098] -[0100] of McCanne et al. In paragraph [0098] McCanne et al. proposes 
that "a far more stable business model [to that of the prior art] is the 'content peering' model 
described herein." In paragraph [0100], McCanne et al. states that "a set of ISPs can more easily 
than before develop their own content distribution service by peering at the "content level" rather 
than the network level." (Emphasis supplied.) McCanne et al. illustrates peering at the network 
level in Fig. 2, link 29. (See paragraph [0100], lines 6-7.) In contrast, McCanne et al. illustrates 
peering at the network edge by ISPs in Fig. 8. In paragraph [0108], with respect to Fig. 8, 
McCanne et al. states: 

a peer ISP can build its own content distribution network using the present 
invention to "peer" with the content backbone to incrementally build out 
the content network. (Paragraph [0108], lines 4-6.) 

From this quote, it is clear that the McCanne et al. is concerned with a build-out of a 
content distribution network to the network edge, and not on the client side. Even more to the 
point, McCanne et al. goes on to say in paragraph [0109]: 

Not only does this ISP's deployment of content distribution technology 
reduce bandwidth costs and provide better network quality to users, but it 
creates a new revenue opportunity by allowing that ISP to enter into the 
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content distribution service. That is, the second ISP would create and own 
its own URL namespace anchored in its own content backbone. Then, its 
affiliate ISPs configure their content redirectors to capture the new URLs, 
assuming a business relationship exists to support this level of "content 
peering". In effect, the content distribution architecture described 
herein allows any ISP to build their own content backbone and 
content distribution service offering, then peer with one another— at the 
content level rather than the IP layer-to effect arbitrarily large and 
wide-reaching content distribution networks. (Emphasis supplied.) 

Thus, the arrangement proposed by McCanne et al. clearly is directed to ISP peering, and 
not client-side peering. 

It is submitted that claim 1 is not anticipated by McCanne et al. In addition, we reiterate 
that McCanne et al.'s approach to solving bandwidth problems is from the network side, 
specifically, at the network edge, and therefore does not suggest the invention as claimed in 
claim 1. Based on the foregoing, it is submitted that claim 1 is allowable over McCanne et al. 

Independent Claim 12 

For similar reasons, it is submitted that claim 12 is not anticipated by or obvious from 
McCanne et al., and is allowable over McCanne et al. 

Independent Claim 20 

It is submitted that claim 20 is allowable for reasons similar to those advanced for the 
allowability of claim 1, and for the following reasons. 

Claim 20 claims forming a multicast group comprising user terminals that have provided 
requests for the streamed content, and providing a streamed unicast transmission of the requested 
content for receipt by a client-side computer in the client network. The received content is 
processed in the client-side computer such that the content is suitable for distribution to the 
multicast group, and the client-side computer distributes the processed streamed content to each 
of the requesting user terminals of the client network in the multicast group. 

The activities in claim 20 summarized above, e.g., distributing processed content from 
the client-side computer to requesting terminals in the multicast group of the client network, all 
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occur on the client side of the network, which, as discussed above, McCanne et al. does not 
disclose. 

Independent claim 23 

Claim 23 has been amended from a dependent to an independent claim. It is submitted 
that claim 23 is allowable over McCanne et al. for reasons similar to those advanced for the 
allowability of claim 1, and because McCanne et al. does not disclose monitoring at the client- 
side computer as claimed in claim 23. (The Examiner cited to paragraph [0208] in the support of 
the claim 23 rejection. However, paragraph [0208] refers to the local servers 201 and 202 which 
are on the network side of the end host 100 and any client for which the end host is an 
attachment point to the network.) 

Dependent Claims 2, 5, 6, 8, 9. IK 13, 18, 19 and 24-26 

At least dependent claims 2, 8, 9 (dependent upon claim 1), dependent claims 13 and 19 
(dependent upon independent claim 12), and dependent claims 24-26 (dependent on independent 
claim 23), involve activities occurring in the client network. Claims 5 and 6, which are 
dependent on claim 1, involve transmitting addition content to the client-side terminal. As 
discussed above, McCanne et al. does not address such activities on the client side of the 
network, if at all. 

It is submitted that dependent claims 2, 5, 6, 8, 9, 1 1, 13, 18, 19 and 24-26 are allowable 
for the reasons discussed above and for reasons similar to those advanced for the allowability of 
claim 1. 

In the interests of brevity, this response does not comment on each and every comment 
made by the Examiner in the Office Action because the primary reference does not describe the 
client-side structure and functionality described in the claims presented herein, which moots the 
basis for almost all of the comments. This should not be taken as acquiescence of the substance 
of those comments. 
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35 USC S 103 Rejection of Dependent Claims 4. 7 and 14-1 7 

It is submitted that dependent claims 4, 7 and 14-17, which are dependent on claim 1 or 
independent claim 12, are allowable for reasons similar to those advanced for the allowability of 
claim 1 and certain dependent claims. Nothing in McHale et al. and Khan et al. includes the 
disclosure or any suggestion thereof missing from McCanne et al., as discussed above. 

New Claims 27-30 

It is submitted that that added claims 27-30 are also allowable over McCanne et al. and 
the prior art of record. Among other things, like claim 1, these claims provide for a client-side 
computer in the client network that receives, process and distributes streamed content. 

Closing 

It is submitted that claims 1, 2, 4-9, 1 1-20 and 23-30 are allowable. Reconsideration and 
allowance of the application with those claims are requested. 

Respectfully submitted, 
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